Existing technologies allow a device (home appliances, digital appliances, etc.) in a local network such as a home local area network (LAN) to be controlled by a control device such as a user terminal (PC, smartphone, etc.). According to generally known methods, an application for controlling the device, which is installed on the user terminal, discovers the device in the local network to be connected to the discovered terminal. In this context, according to existing methods, UDP-protocol-based device discovery protocols such as mDNS, UPnP, and ECHONET™ may be used to discover the device by the application of the user terminal and establish the connection channel for interaction. Also, according to other methods, a communication medium such as Bluetooth™ and Wi-Fi may be used to support the device discovery in a communication layer lower than the above-mentioned layer. In the case of Wi-Fi, the device includes a Wi-Fi access point (hereinafter referred to as “AP”) function, an SSID of this Wi-Fi AP is selected by the user terminal, and thus the user terminal is allowed to be connected to the device.
The method that uses the UDP-based device discovery protocol cannot be used for a Web page that operates on the Web browser (hereinafter referred to as “Web front-end”). This is because the device discovery protocol cannot be used via the Web front-end. A dedicated application needs to be compliant with various types of smartphones and OS versions, which requires development costs.
Meanwhile, the method that uses Wi-Fi can be used via the Web front-end. According to this method, although no dedicated application needs to be provided, the device needs to incorporate the AP mode. In general, incorporation of the AP mode requires more cost than in the case where it does not need to be incorporated. Also, with regard to Bluetooth, it is possible that Bluetooth becomes available in the future via the Web front-end but it cannot be currently used. Even when it becomes available in the future, the device needs to incorporate the Bluetooth feature. In the case of a device that has the Internet connection function, the device needs to include a Wi-Fi or wired LAN interface, in addition to which incorporation of the Bluetooth feature leads to increase in the costs as in the case of incorporation of the AP mode.
Some methods have been proposed such as a method that has the advantages of the above-described two methods, i.e. a method that does not need to incorporate in the device the module such as the Wi-Fi AP mode and the Bluetooth feature, which causes increase in the costs, and carries out pairing via the Web front-end between the user terminal and the device in the local network. Pairing as used herein refers to allowing the device on the local network to be controlled by the user terminal by specifying the user terminal and the device as a pair of devices between which communications are allowed.
As the method of pairing, for example, a method has been disclosed according to which passcode-based pairing of the user and the device is carried out on a cloud. However, pairing that solely relies on a passcode is susceptible to brute-force attacks. Specifically, if a passcode of four-digit numerical data is to be entered, then only one hundred thousand passcodes from 0000 to 9999 are available, so that it is possible to cause the pairing between the user and the device to fail by making an access by randomly selecting the numerical values. Although the resistance (to brute-force attacks) can be increased by making the passcode sufficiently long, such a sufficiently long pass code is not without a problem. The device will have to include a device capable of displaying the long passcode. Also, the user needs to take labor and time or may make erroneous inputs, which causes degradation in the usability associated with the long passcode.